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AMENDMENTS TO THE DRAWINGS 



Please amend the above-identified application as follows: 



In the Drawings : 



The OiFice Action states at page 2: 

The drawings are objected to as failing to comply with 37 CFR § 
1 .84(p)(4) because reference character "3 1 6" has been used to 
designate both the 'Rows' in the Fact Table - 312 and 'Dependencies' 
in database - 308. 

In this Response, Applicants amend Figure 3 to remove the objection. That is, Applicants 
amend Figure 3 by changing from '316' to '315' the reference character designating 
Rows in Fact Table 312. 

Attachment: Replacement Sheet 3 

Annotated Sheet Showing the Change 
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REMARKS 



Claims 1, 7, and 13 stand rejected under 35 U.S.C § 102(b) as being anticipated by 
Weissman, et al (U.S. Patent No. 6,212,524). Claims 2, 8, and 14 stand rejected for 
obviousness under 35 U.S.C § 103(a) as being unpatentable over Weissman, et al (U.S. 
Patent No. 6,212,524), in view of Veronese, et al (U.S. Patent App. Pub. No. 
2004/0210445). Claims 3-6, 9-12, and 15-18 stand rejected for obviousness under 35 
U.S.C § 103(a) as being unpatentable over Weissman, et al (U.S. Patent No. 6,212,524), 
in view of Veronese, et al (U.S. Patent App. Pub. No. 2004/0210445) and further in view 
of Medicke, et al (U.S. Patent App. Pub. No. 2004/0236786). As is shown below, 
Weissman does not anticipate populating a database as claimed in the present application 
nor does any combination of Weissman, Veronese, and Medicke make obvious populating 
a database as claimed in the present application. 



Claim Rejections ~ 35 U>S,C. S102 Over Weissman 



Claims 1, 7, and 13 stand rejected under 35 U.S.C § 102(b) as being anticipated by 
Weissman, et al (U.S. Patent No. 6,212,524). To anticipate claims 1, 7, and 13 under 35 
U.S.C. § 102(b), two basic requirements must be met. The first requirement of 
anticipation is that Weissman must disclose each and every element as set forth in 
Applicants' claims. The second requirement of anticipation is that 
Weissman must enable Applicants' claims. Weissman does not meet either requirement 
and therefore does not anticipate Applicants' claims. Claims 1, 7, and 13 are therefore 
patentable and should be allowed. Applicants respectfully traverse each rejection 
individually below and request reconsideration of claims 1, 7, and 13. 
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Weissman Does Not Disclose Each and Every Element 
Of The Claims Of The Present Application 

"A claim is anticipated only if each and every element as set forth in the claim is found, 
either expressly or inherently described, in a single prior art reference." Verdegaal Bros. 
V. Union Oil Co, of California, 814 F.2d 628, 631, 2 USPQ2d 1051, 1053 (Fed. Cir. 
1987). As explained in more detail below, Weissman does not disclose each and every 
element of claim 1, and Weissman therefore cannot be said to anticipate the claims of the 
present application within the meaning of 35 U.S. C. 102. 

Independent claim 1 claims: 

A method for populating a database, the method comprising: 

providing a database having a schema; 

inferring from the schema dependencies among a fact table and related 
dimension tables; and 

inserting, in accordance with the dependencies, rows of data into the fact 
table and rows of data into the dimension tables. 

Weissman Does Not Disclose 
Inferring From The Schema Dependencies Among 
A Fact Table And Related Dimension Tables 

Regarding the second element of claim 1, the Office Action states that Weissman at 
colunm 3, lines 1-2; colximn 3, lines 36-38; column 5, lines 36-32; column 7, lines 42-49; 
and column 10, lines 24-42 discloses: 

inferring from the schema dependencies among a fact table and related 
dimension tables (Weissman: Column 3, lines 1-2, and lines 36-38; 
Column 5, lines 36-32; Column 7, lines 42-49; Column 10, lines 24-42) 
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That is, the Office Action takes the position that Weissman at column 3, lines 1-2; 
column 3, lines 36-38; column 5, lines 36-32; column 7, lines 42-49; and column 10, 
lines 24-42 discloses the second element of claim 1 . Applicants respectfully note in 
response, however, that Weissman at column 3, lines 1-2; column 3, lines 36-38; column 
5, lines 36-32; column 7, lines 42-49; and column 10, lines 24-42 does not disclose the 
second element of claim 1 . What Weissman at column 3, lines 1-2, in fact discloses is: 
"The schema defines the relationships between the tables and columns." The schema of 
Weissman does not disclose inferring from the schema dependencies among a fact table 
and related dimension tables as claimed in the present application. 

What Weissman at column 3, lines 36-38 discloses is: 

In some embodiments, the schema is a star schema having one or more 
fact tables and one or more dimension tables (or dimensions). The schema 
can be held in a constellation that includes additional information. The 
constellation can correspond to a business process. 

The star schema having fact tables and dimension tables of Weissman does not disclose 
inferring from the schema dependencies among a fact table and related dimension tables 
as claimed in the present application. 

What Weissman at column 5, lines 26-32 discloses is: 

Focusing on the datamart creation, the system allows a consultant to build 
a datamart from a schema definition of the sources of the data. From the 
schema definition the system automatically builds the table needed in the 
datamart. Also, from the schema definition, and the sources definition, the 
system can automatically extract the data from those sources. 

The datamart creation system of Weissman does not disclose inferring from the schema 
dependencies among a fact table and related dimension tables as claimed in the present 
application. 

What Weissman at column 7, lines 42-49 discloses is: 
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What is important is that the consuhant can easily define a schema for the 
datamart 150 and that definition is kept in the schema definitions 16L 
From the schema definitions 161, not only can the tables in the datamart 
150 be generated, but also the automatic extraction and conversion of the 
data from the source system 1 10 can be performed, aggregates are set up, 
and a query mechanism is generated. 

The schema definitions of Weissman do not disclose inferring from the schema 
dependencies among a fact table and related dimension tables as claimed in the present 
application. 



What Weissman at column 10, lines 24-42 discloses is: 



At block 210, a consultant uses the enterprise manager 102 to define the 
schema. The schema is defined using the metadata 160. This process is 
illustrated in greater detail in FIG. 7 through FIG. 35. Generally, defining 
the schema involves determining the business processes of the 
organization for w^hich the system 100 is being implemented. The 
consultant then defines the star schema for those business processes. The 
star schema has a fact table and a number of dimensions. The consultant 
also defines from where the data in the schema is to be derived. That is, 
the consultant defines from which fields and tables the information is to be 
extracted from the source systems 110. The consultant also defines how 
that data is to be put into the datamart 150. That is, the consultant 
associates each piece of data with a semantic meaning. This semantic 
meaning defines how the data from the source system is to be manipulated 
and how it is to populate the datamart 150. At this point, the consultant 
can also define the aggregates that can be used in the datamart 150. 

The schema definition process of Weissman does not disclose inferring from the schema 
dependencies among a fact table and related dimension tables as claimed in the present 
application. 
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Weissman Does Not Disclose 
Inserting Rows Of Data Into The Tables In 
Accordance With The Dependencies 

Regarding the third element of claim 1 , the Office Action states that Weissman at column 
3, lines 1-11, and column 10, lines 24-42 discloses: 

Inserting, in accordance with the dependencies, rows of data into the fact 
table and rows of data into the dimensions tables (Weissman: Column 3, 
lines 1-11; Column 1 0, lines 24-42). 

That is, the Office Action takes the position that Weissman at column 3, lines 1-11, and 
column 10, lines 24-42 discloses the third element of claim 1 . Applicants respectfully 
note in response, however, that Weissman at column 3, lines 1-11, and column 10, lines 
24-42 does not disclose the third element of claim 1 . What Weissman at column 3, lines 
1-1 1, in fact discloses is: 



The schema defines the relationships between the tables and columns. The 
description further defines how data is to be manipulated and used to 
populate the tables in the datamart. That is, the description defines the 
semantic meaning of the data. The description is further used to create a 
set of commands to create the tables. The commands are executed causing 
the creation of the tables. Importantly, when the semantic meaning is 
associated with the column and rows, programs for manipulating and 
propagating data into those columns and rows are automatically defined. 

The schema, description and commands of Weissman do not disclose inserting, in 
accordance with the dependencies, rows of data into the fact table and rows of data into 
the dimension tables as claimed in the present application. 

What Weissman at column 10, lines 24-42 discloses is: 

At block 210, a consultant uses the enterprise manager 102 to define the 
schema. The schema is defined using the metadata 160. This process is 
illustrated in greater detail in FIG. 7 through FIG. 35. Generally, defining 
the schema involves determining the business processes of the 
organization for which the system 100 is being implemented. The 
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consultant then defines the star schema for those business processes. The 
. star schema has a fact table and a number of dimensions. The consultant 
also defines from where the data in the schema is to be derived. That is, 
the consultant defines fi-om which fields and tables the information is to be 
extracted from the source systems 110. The consultant also defines how 
that data is to be put into the datamart 150. That is, the consultant 
associates each piece of data with a semantic meaning. This semantic 
meaning defines how the data from the source system is to be manipulated 
and how it is to populate the datamart 1 50. At this point, the consultant 
can also define the aggregates that can be used in the datamart 1 50. 

The schema definition process of Weissman does not disclose inserting, in accordance 
with the dependencies, rows of data into the fact table and rows of data into the 
dimension tables as claimed in the present application. 

Weissman Does Not Place One Of Ordinary Skill In The 
Art In Possession Of Each and Every Element 
Of The Claims Of The Present Application 

Not only must Weissman disclose each and every element of the claims of the present 
application within the meaning of Verdegaal in order to anticipate Applicants' claims, 
but also Weissman must be an enabling disclosure of each and every element of the 
claims of the present application within the meaning of In re Hoeksema. In Hoeksema, 
the claims were rejected because an earlier patent disclosed a structural similarity to the 
applicant's chemical compound. The court in Hoeksema stated: "We think it is sound 
law, consistent with the public policy underlying our patent law, that before any 
publication can amount to a statutory bar to the grant of a patent, its disclosure must be 
such that a skilled artisan could take its teachings in combination with his own 
knowledge of the particular art and be in possession of the invention." In re Hoeksema, 
399 F.2d 269, 273, 158 USPQ 596, 600 (CCPA 1968). The meaning Hoeksema for 
the present case is that unless Weissman places Applicants' claims in the possession of a 
person of ordinary skill in the art, Weissman is legally insufficient to anticipate 
Applicants' claims under 35 USC 102(b). 
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Weissman Does Not Enable 
Inferring From The Schema Dependencies Among 
A Fact Table And Related Dimension Tables 

Regarding the second element of claim 1, the Office Action states that Weissman at 
colxrnm 3, lines 1-2; column 3, lines 36-38; column 5, lines 36-32; column 7, lines 42-49; 
and column 10, lines 24-42 discloses: 

inferring from the schema dependencies among a fact table and related 
dimension tables (Weissman: Column 3, lines 1-2, and lines 36-38; 
Column 5, lines 36-32; Column 7, lines 42-49; Column 10, lines 24-42) 

That is, the Office Action takes the position that Weissman at column 3, lines 1-2; 
column 3, lines 36-38; colxmin 5, lines 36-32; column 7, lines 42-49; and column 10, 
lines 24-42 places one of ordinary skill in the art in possession of the second element of 
claim L Applicants respectfully note in response, however, that Weissman at column 3, 
lines 1-2; column 3, lines 36-38; column 5, lines 36-32; column 7, lines 42-49; and 
column 10, lines 24-42 does not place one of ordinary skill in the art in possession of the 
second element of claim 1. What Weissman at column 3, lines 1-2, discloses is: "The 
schema defines the relationships between the tables and columns." The schema of 
Weissman does not place one of ordinary skill in the art in possession of inferring from 
the schema dependencies among a fact table and related dimension tables as claimed in 
the present application. 

What Weissman at column 3, lines 36-38 discloses is: 

In some embodiments, the schema is a star schema having one or more 
fact tables and one or more dimension tables (or dimensions). The schema 
can be held in a constellation that includes additional information. The 
constellation can correspond to a business process. 
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The star schema having fact tables and dimension tables of Weissman does not place one 
of ordinary skill in the art in possession of inferring from the schema dependencies 
among a fact table and related dimension tables as claimed in the present application. 

What Weissman at column 5, lines 26-32 discloses is: 

Focusing on the datamart creation, the system allows a consultant to build 
a datamart from a schema definition of the sources of the data. From the 
schema definition the system automatically builds the table needed in the 
datamart. Also, from the schema definition, and the sources definition, the 
system can automatically extract the data from those sources. 

The datamart creation system of Weissman does not place one of ordinary skill in the art 
in possession of inferring from the schema dependencies among a fact table and related 
dimension tables as claimed in the present application. 



What Weissman at column 7, Unes 42-49 discloses is: 



What is important is that the consultant can easily define a schema for the 
datamart 150 and that definition is kept in the schema definitions 161. 
From the schema definitions 161, not only can the tables in the datamart 
150 be generated, but also the automatic extraction and conversion of the 
data from the source system 110 can be performed, aggregates are set up, 
and a query mechanism is generated. 

The schema definitions of Weissman do not place one of ordinary skill in the art in 
possession of inferring from the schema dependencies among a fact table and related 
dimension tables as claimed in the present application. 

What Weissman at column 10, lines 24-42 discloses is: 



At block 210, a consultant uses the enterprise manager 102 to define the 
schema. The schema is defined using the metadata 160. This process is 
illustrated in greater detail in FIG. 7 through FIG. 35. Generally, defining 
the schema involves determining the business processes of the 
organization for which the system 100 is being implemented. The 
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consultant then defines the star schema for those business processes. The 
star schema has a fact table and a number of dimensions. The consultant 
also defines from where the data in the schema is to be derived. That is, 
the consultant defines from which fields and tables the information is to be 
extracted from the source systems 1 10. The consultant also defines how 
that data is to be put into the datamart 150. That is, the consultant 
associates each piece of data with a semantic meaning. This semantic 
meaning defines how the data from the source system is to be manipulated 
and how it is to populate the datamart 150. At this point, the consultant 
can also define tiie aggregates that can be used in the datamart 1 50. 

The schema definition process of Weissman does not place one of ordinary skill in the art 
in possession of inferring from the schema dependencies among a fact table and related 
dimension tables as claimed in the present application. 



Weissman Does Not Place One Of Ordinary Skill In The Art In 
Possession Of Inserting Rows Of Data Into The 
Tables In Accordance With The Dependencies 

Regarding the third element of claim 1, the Office Action states that Weissman at column 
3, lines 1-11, and column 10, lines 24-42 discloses: 



Inserting, in accordance with the dependencies, rows of data into the fact 
table and rows of data into the dimensions tables (Weissman: Colunm 3, 
lines 1-11; Column 10, lines 24-42). 

That is, the Office Action takes the position that Weissman at colunm 3, lines 1-11 and 
colunm 10, lines 24-42 place one of ordinary skill in the art in possession of the third 
element of claim 1. Applicants respectfully note in response, however, that Weissman at 
column 3, lines 1-11, and column 10, lines 24-42 does not place one of ordinary skill in 
the art in possession of the third element of claim 1. What Weissman at column 3, lines 
1-1 1, in fact discloses is: 



The schema defines the relationships between the tables and columns. The 
description further defines how data is to be manipulated and used to 
populate the tables in the datamart. That is, the description defines the 
semantic meaning of the data. The description is further used to create a 
set of commands to create the tables. The commands are executed causing 
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the creation of the tables. Importantly, when the semantic meaning is 
associated with the column and rows, programs for manipulating and 
propagating data into those columns and rows are automatically defined. 

The schema, description and commands of Weissman do not place one of ordinary skill 
in the art in possession of inserting, in accordance with the dependencies, rows of data 
into the fact table and rows of data into the dimension tables as claimed in the present 
application. 

What Weissman at colimm 10, lines 24-42 discloses is: 



At block 210, a consultant uses the enterprise manager 102 to define the 
schema. The schema is defined using the metadata 160. This process is 
illustrated in greater detail in FIG. 7 through FIG. 35. Generally, defining 
the schema involves determining the business processes of the 
organization for which the system 100 is being implemented. The 
consultant then defines the star schema for those business processes. The 
star schema has a fact table and a number of dimensions. The consultant 
also defines from where the data in the schema is to be derived. That is, 
the consultant defines from which fields and tables the information is to be 
extracted fi"om the source systems 1 10. The consultant also defines how 
that data is to be put into the datamart 1 50. That is, the consultant 
associates each piece of data with a semantic meaning. This semantic 
meaning defines how the data from the source system is to be manipulated 
and how it is to populate the datamart 150. At this point, the consultant 
can also define the aggregates that can be used in the datamart 150. 

The schema definition process of Weissman does not place one of ordinary skill in the art 
in possession of inserting, in accordance with the dependencies, rows of data into the fact 
table and rows of data into the dimension tables as claimed in the present application 



Claim Rejections - 35 U,S,C, S 103 

Claims 2, 8, and 14 stand rejected for obviousness under 35 U.S.C § 103(a) as being 
unpatentable over Weissman, et al (U.S. Patent No. 6,212,524), in view of Veronese, et 
al (U.S. Patent App. Pub. No. 2004/0210445). Additionally, claims 3-6, 9-12, and 15-18 
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stand rejected for obviousness under 35 U.S.C § 103(a) as being unpatentable over 
Weissman, et al (U.S. Patent No. 6,212,524), in view of Veronese, et al (U.S. Patent 
App. Pub. No. 2004/0210445) and further in view of Medicke, etal (U.S. Patent App. 
Pub. No. 2004/0236786). As is shown below, neither Weissman nor Veronese nor 
Medicke, either alone or in combination, teaches or suggests a method, system, or 
computer program product for populating a database as claimed in the present 
application. Claims 2-6, 8-12, and 14-18 are therefore patentable and should be allowed. 
Applicants respectfully traverse each rejection individually and request reconsideration of 
claims 2-6, 8-12, and 14-18. 

Weissman And Veronese 

Claims 2, 8, and 14 stand rejected under 35 U.S.C § 103(a) as unpatentable over 
Weissman in view of Veronese. To establish a prima facie case of obviousness, several 
basic criteria must be met. Manual of Patent Examining Procedure §2 142. The first 
element of a prima facie case of obviousness under 35 U.S.C. § 103 is that the proposed 
combination of the references must teach or suggest all of Applicants' claim limitations. 
In re Royka, 490 F.2d 981, 985, 180 USPQ 580, 583 (CCPA 1974). The second element 
of a prima facie case of obviousness under 35 U.S.C. § 1 03 is that there must be a 
suggestion or motivation to combine the references. In re Vaeck, 947 F.2d 488, 493, 20 
USPQ2d 1438, 1442 (Fed. Cir. 1991). 

The Combination Of Weissman And Veronese 
Does Not Teach Ail Of Applicants^ Claim Limitation 

To establish a prima facie case of obviousness, the proposed combinations of the 
references must teach or suggest all of the claim limitations of claims 2, 8, and 14. In re 
Royka, 490 F.2d 981, 985, 180 USPQ 580, 583 (CCPA 1974). Claims 2, 8, and 14 
depend from claims 1, 7, and 13, respectively, and include all of the limitations of the 
claims from which they depend. Because the proposed combination of Weissman and 
Veronese relies on the argument that Weissman teaches each and every element of claims 
1, 7, and 13, and because Weissman in fact does not teach or suggest each and every 
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element of claims 1, 7, and 13, the proposed combination cannot teach or suggest all the 
claim limitations of claims 2, 8, and 14. The proposed combination therefore cannot 
establish a prima facie case of obviousness and the rejections should be withdrawn. 

No Suggestion Or Motivation To Combine Weissman And Veronese 

To establish a prima facie case of obviousness, there must be a suggestion or motivation 
to combine Weissman and Veronese. In re Vaeck, 947 F.2d 488, 493, 20 USPQ2d 1438, 
1442 (Fed. Cir. 1991). The suggestion or motivation to combine Weissman and 
Veronese must come from the teaching of the references themselves, and the Examiner 
must explicitly point to the teaching within the references suggesting the proposed 
modification. Absent such a showing, the Examiner has impermissibly used "hindsight" 
occasioned by Applicants' own teaching to reject the claims. In re Surko, 1 1 F.3d 887, 
42 U.S.P.Q.2d 1476 (Fed. Cir. 1997); In re Vaeck 947 F.2d 488m 20 U.S.P.Q.2d 1438 
(Fed. Cir. 1991); In re Gorman, 933 F.2d 982, 986, 18 U.S.P.Q.2d 1885, 1888 (Fed. Cir. 
1991); In re Bond, 910 F.2d 831, 15 U.S.P.Q.2d 1566 (Fed. Cir. 1990); In re Laskowski, 
871 F.2d 115, 117, 10U.S.P.Q.2d 1397, 1398 (Fed. Cir. 1989). 

The Office Action at page 6 states its rationale for the motivation to combine as: 

The suggestion or motivation of doing so would be to have new 
development methodologies, which will be both rapid and easily 
manageable and modifiable by the users (Veronese: Paragraph 1 1, lines 3- 
5). 

And further motivation would be to have an improved data warehousing 
technology (Weissman: Column 2, lines 61-62). 
Therefore, it would have been obvious to have added Weissman with 
Veronese for the benefit of new development methodologies and 
improved data warehousing technology. 

In fact, read in context, Veronese at paragraph 11, lines 3-5, merely describes in general 
terms a need for new development technologies for "defining organizations of 
companies, their business processes and their business rules in a declarative manner," 
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(Veronese, paragraph 12, lines 2-4) suggesting nothing whatsoever about combining 
Weissman with Veronese. Moreover, Weisman at colunm 2, lines 61-62 merely states, 
"Thus an improved data warehousing technology is desired," suggesting nothing 
whatsoever about combining Weissman with Veronese. As such, the proposed 
combination of Weissman and Veronese cannot establish a prima facie case of 
obviousness. 

Weissman, Veronese And Medicke 

Claims 3-6, 9-12, and 15-18 stand rejected under 35 U.S.C § 103(a) as unpatentable over 
Weissman, et al (U.S. Patent No. 6,212,524), in view of Veronese, et aL (U.S. Patent 
App. Pub. No. 2004/0210445) and further in view of Medicke, et al (U.S. Patent App. 
Pub. No. 2004/0236786. In response. Applicants attach to this Response a declaration 
pursuant to 37 CFR § 1.131 proving that the invention of this application was completed 
in the United States at a date prior to May 22, 2003, the effective date of Medicke. 
Because this invention was completed in the United States prior to the effective date of 
Medicke, Medicke is unavailable as a reference against this invention, and claims to this 
invention cannot be rejected under 35 U.S.C. § 103(a) on the basis of any combination 
that includes Medicke. Moreover, as pointed out in more detail below, even if Medicke 
were available as a reference, the proposed combination of Weissman, Veronese, and 
Medicke would provide no basis for a prima facie case of obviousness. For all these 
reasons therefore, the rejection of claims 3-6, 9-12, and 15-18 should be withdrawn, and 
claims 3-6, 9-12, and 15-18 should be allowed. 

The Combination Of Weissman, Veronese And Medicke 
Does Not Teach All Of Applicants^ Claim Limitation 

To establish a prima facie case of obviousness, the proposed combinations of the 
references must teach or suggest all of the claim limitations of claims 3-6, 9-12, and 15- 
18. In re Royka, 490 F.2d 981, 985, 180 USPQ 580, 583 (CCPA 1974). Claims 3-6, 9- 
12, and 15-18 depend from claims 1, 7, and 13, respectively, and include all of the 
limitations of the claims from which they depend. Because the proposed combination of 
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Weissman, Veronese and Medicke relies on the argument that Weissman teaches each 
and every element of claims 1, 7, and 13, and because, as described in detail above in this 
Response, Weissman in fact does not teach or suggest each and every element of claims 
1, 7, and 13, the proposed combination cannot teach or suggest all the claim limitations of 
claims 3-6, 9-12, and 15-18. The proposed combination therefore cannot establish a 
prima facie case of obviousness and the rejections should be withdrawn. 

No Suggestion Or Motivation To Combine Weissman, Veronese And Medicke 

To establish a prima facie case of obviousness, there must be a suggestion or motivation 
to combine Weissman, Veronese and Medicke. In re Vaeck, 947 F.2d 488, 493, 20 
USPQ2d 1438, 1442 (Fed. Cir. 1991). The suggestion or motivation to combine 
Weissman, Veronese and Medicke must come from the teaching of the references 
themselves, and the Examiner must explicitly point to the teaching within the references 
suggesting the proposed modification. Absent such a showing, the Examiner has 
impermissibly used "hindsight" occasioned by Applicants' own teaching to reject the 
claims. In re Surko, 1 1 F.3d 887, 42 U.S.P.Q.2d 1476 (Fed. Cir. 1997); In re Vaeck, 947 
F.2d 488m 20 U.S.P.Q.2d 1438 (Fed. Cir. 1991); In re Gorman, 933 F.2d 982, 986, 18 
U.S.P.Q.2d 1885, 1888 (Fed. Cir. 1991); In re Bond, 910 F.2d 831, 15 U.S.P.Q.2d 1566 
(Fed. Cir. 1990); In re Laskowskh 871 F.2d 115, 117, 10U.S.P.Q.2d 1397, 1398 (Fed. 
Cir. 1989). 

The Office Action at page 8 states its rationale for the motivation to combine as: 

The suggestion or motivation of doing so would be to generate a data 
warehouse by incorporating data warehouse information in business 
objects to provide subscribed business objects and generating star-schema 
tables of data warehouse from the subscribed business objects (Medicke, 
Paragraph 9). Therefore, it would have been obvious to combine 
Weissman, Veronese, and Medicke for the benefit of generating a data 
warehouse. 
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In fact, Medicke at paragraph 9, merely describes embodiments of the Medicke invention 
for generating a data warehouse suggesting nothing whatsoever about combining 
Medicke with Weissman, and Veronese. As such, the proposed combination of 
Weissman, Veronese, and Medicke cannot establish a prima facie case of obviousness. 

Relations Among Claims 

Independent claims 7 and 13 are system and computer program product claims for 
populating a database corresponding to independent method claim 1 that include "means 
for" and "means, recorded on [a] recording medium, for" populating a database. Claims 
2-6, 8-12, and 14-18 depend respectively from independent claims 1, 7, and 13. Each 
dependent claim includes all of the limitations of the independent claim from which it 
depends. Because Weissman does not disclose and enable each and every element of the 
independent claims, Weissman does not disclose and enable each and every element of 
the dependent claims of the present application. As such, claims 2-6, 8-12, and 14-18 are 
also patentable and should be allowed. 

Conclusion 

Claims 1, 7, and 13 stand rejected under 35 U.S.C § 102(b) as being anticipated by 
Weissman, et al (U.S. Patent No. 6,212,524). Weissman does not disclose each and 
every element of Applicants' claims, and Weissman does not enable Applicants' claims. 
Weissman therefore does not anticipate Applicants' claims within the meaning of 35 
U.S.C § 102(e). Claims 2, 8, and 14 stand rejected for obviousness under 35 U.S.C § 
103(a) as being unpatentable over Weissman, et al (U.S. Patent No. 6,212,524), in view 
of Veronese, etal (U.S. Patent App. Pub. No. 2004/0210445). Claims 3-6, 9-12, and 15- 
18 stand rejected for obviousness under 35 U.S.C § 103(a) as being unpatentable over 
Weissman, et al (U.S. Patent No. 6,212,524), in view of Veronese, et al (U.S. Patent 
App. Pub. No. 2004/0210445) and further in view of Medicke, et al (U.S. Patent App. 
Pub. No. 2004/0236786). For the reasons set forth above, however, the proposed 
combination of Weissman and Veronese, and the proposed combination of Weissman, 
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Veronese, and Medicke each fail to establish a prima face case of obviousness. The 
rejection of claims 1-18 should therefore be withdrawn, and the claims should be 
allowed. Reconsideration of claims 1-18 in light of the present remarks is respectfully 
requested. 

The Commissioner is hereby authorized to charge or credit Deposit Account No. 09-0447 
for any fees required or overpaid. 



Respectfully submitted, 



Date: April 10. 2006 




H. ArtouslTolianimr 

Reg. No. 46,022 

Biggers & Ohanian, LLP 

P.O. Box 1469 

Austin, Texas 78767-1469 

Tel. (512) 472-9881 

Fax (512) 472-9887 

ATTORNEY FOR APPLICANTS 
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